home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 876 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.5 KB

  1. From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
  2. Message-ID: <4jboij$4t3@mulga.cs.mu.OZ.AU>
  3. X-Original-Date: 27 Mar 1996 15:58:11 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 27 Mar 96 17:03:40 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Placement delete suggestion Keywords: delete placement
  9. Organization: Comp Sci, University of Melbourne
  10. References: <4j4ec5$d41@fsgi01.fnal.gov> <9603261124.AA22276@lts.sel.alcatel.de>
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMVl08uEDnX0m9pzZAQFogAF9HU3Izp3V4ztevaer+tZDMaHGOrXPydGp
  13.     kBaTDlvsWWJ4Sb9b7X1JkxzWTIS8XSMF
  14.     =exTH
  15.  
  16. James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> writes:
  17.  
  18. >b91926@fsgi01.fnal.gov (David Sachs) writes:
  19. >
  20. >|> The lack of a placement delete expression form, corresponding to
  21. >|> the placment new form, has been a topic for serious discussion in
  22. >|> this group.  The obvious problem with placement delete is that
  23. >|> any non-awkward form could be ambiguous, though examples that
  24. >|> would show such ambguity are probably infrequent.
  25. >
  26. >|> In view of this, it might be reasonable if the standards committee
  27. >|> bit the bullet and declare that such ambiguous forms should be
  28. >|> treated as placement deletes.
  29. >
  30. >Is the expression: delete (*pf)( p ) placement delete or not? 
  31.  
  32. That would be placement delete.
  33.  
  34. >(The variable pf has type `T* (*)( T* )', and p type T*.) 
  35.  
  36. Irrelevant, as far as syntax analysis goes -- syntax analysis is not
  37. concerned with the types of variables.
  38.  
  39. Your code is however an example of the sort of code that would
  40. get broken by this proposal.
  41.  
  42. >If not, why not?
  43. >If so, how can I remove the ambiguity (by adding parentheses or
  44. >otherwise)?
  45.  
  46. You could remove the ambiguity by writing
  47.  
  48.     delete ((*pf)(p));
  49.  
  50. or simply
  51.  
  52.     delete pf(p);
  53.  
  54. IMHO, David Sach's suggestion is a good one.  Some of the committee
  55. members have tossed around this idea before, although I don't think it
  56. was ever formally proposed.  The fact that it breaks existing code
  57. makes it a hard sell, and Bjarne was opposed to placement delete on the
  58. grounds that "at the point of deletion, the user can't be expected to
  59. know how the object was allocated" (D&E, section 10.5, page 214) and
  60. that consequently "the feature is feared to be error-prone" (ARM,
  61. section 5.3.4, page 66).
  62.  
  63. The argument on the grounds of "protecting people against themselves" (D&E)
  64. doesn't really convince me, since as the ARM says, "added syntax isn't
  65. needed, since the problem can be solved without it".  Rather than
  66. protecting them, you end up just forcing them to use an unintuitive
  67. syntax.
  68.  
  69. The ARM continues: "The question is if such use is common enough to
  70. warrant the support of a special syntax.".  I think the answer is yes,
  71. but at this stage I think it is probably too late to do anything
  72. about it.  Not to worry -- it is a pretty minor syntax issue.
  73.  
  74. Or is it?  On second thoughts, I think the work-around suggested in the ARM
  75. of using a my_delete function won't work for array delete, since you
  76. don't know how many elements to delete.  That is rather unfortunate --
  77. it certainly limits the usefulness of placement array new.
  78.  
  79. --
  80. Fergus Henderson                 WWW: http://www.cs.mu.oz.au/~fjh
  81. fjh@cs.mu.oz.au                  PGP: finger fjh@128.250.37.3
  82. ---
  83. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  84. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  85. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  86. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  87. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  88.